Stockholm, June 3rd, 2019 


What standard requirements should be placed on the financial data 
flow from transaction to final report? 


How does the chain of documents appear that are included in the 
financial reporting data flow? 


Transaction => Coding => Statement of balance => Final report 


Transaction, Coding and Final report are self-evident documents, but why 
statement of balance? All software platforms for corporate financial mana- 
gement are based on the fact that coded data is periodically summarized 
as statements of balance. As such, they are sent e.g. to auditors or ac- 
counting consultants and used in the companies’ internal financial analysis 
and management. All accounting financial platforms are built according to 
that method. 


A. The transaction standards 


Business documents (from product catalog to delivery receipt) are all defined 
in the UBL 2.0 or UBL 2.1 standard. Among these business documents 
there are e.g. order and invoice documents that will create transactions. 
Svefaktura (Swedish invoice) is e.g. a Swedish UBL application. 


Submitting transactions to government authorities requires that the transac- 
tions are readable and that they can be signed. Transactions defined in 
UBL are so complex that they are difficult to read. For that reason, they 
should not be submitted to authorities without any form of presentation. A 
type iXBRL solution (See below) would be appropriate, but to export trans- 
actions to authorities is questionable, since such documents contain busi- 
ness secrets. According to the principle of public access, such documents 
will become public documents in Sweden for anyone to download if they 
are submitted to an authority. 


In addition, many business events that occur within the company are coded 
to posts, so it is difficult to get a good picture of the company only based 
on the external transactions. 


Summing up, the transactions are already defined in format, but should not 
be sent to an authority. 


B. Standard requirements for the statements of balance and the final reports 
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For the posting, the software companies' platforms each have their metadata 
and their own structure. They have therefore widely different formats. Here 
a standard would force the software companies to completely redesign their 
platforms. What standard requirements could be set for the other document 
types outside the transactions and the posting, i.e. for the statements of 
balance and the final reports? 


1. It should connect metadata (concepts) to data. 

2. It should be able to have a schema for such connections. 

3. It should be able to split concepts into subgroups (dimensions). 

4. It should be able to link connections between different concepts (meta- 
data). In order to be able to present a report, the standard must be able to 
link order and hierarchy for in-depth concepts (metadata). It must be able 
to link presentation text to the digital name of the concept. Ex: The digital 
concept "Nettoomsattning" should be able to connect to "Net sales" in a 
presentation in English or "Netttoomsattning" in Swedish. 

5. The reports sent from the companies to the report recipient must be made 
in a format that can be signed, i.e. a format that is both readable and is 
downloadable in the recipient's databases. 


What formats of the statement of balance and the final report are current? 


Comma Separated Values (CSV), Tab Separated Values (TSV) or Excel 
do not meet points 1, 2, 3, 4 or 5. 


JSON (Javascript Object Notation) meets pionts 1 and 3. The standard has 
currently drafts for point 2 (schema) and 4 (linkbase), but lacks point 5. 


XML with the framework standard XBRL 2.1 and with the iXBRL as report 
format meets all five points. But is it relevant even for statements of balance? 
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XBRL — instance/ Income statement by nature 


ee 2014-01-01— | 2013-01-01— 

report document _| Creratingincome sods ||) onea 
Net sales 3230700 2822000 
<?xml version="1.0"> Capitalized work 209000 198500 


<xbrl ...> 
<link:schemaRef xlink:type="simple" 
xlink:href="http: //taxonomi.xbr1.se/se/fr/k2/..."/> 
<context id="RES-1"> 
<entity scheme="http://www.bolagsregistret.se">AB Bygg</entity> 


<period> 
<startDate>2013-01-01</startDate> (1. Period start/end 
<endDate>2013-12-31</endDate> 
</period> 
</context> 


<context id="RESO"> 
<entity scheme="http://www.bolagsregistret.se">AB Bygg</entity> 
<period> 
<startDate>2014-01-01</startDate> 
<endDate>2014-12-31</endDate> 


</period> 
<NetSales ... contextRef="RESO">3230700</NetSales> 
<CapitalizedWork ... contextRef="RESO">209000</CapitalizedWork> 
<NetSales... contextRef="RES-1">282200</NetSales> 
<CapitalizedWork ... contextRef="RES-1">198500</CapitalizedWork> 
</xbr1> 


SIE — instance/report document 


Statement of balance in SIE format: 


#FORMAT PC8 

#SIETYP 1 

#ORGNR 5566440000 

#FNAMN "™"verby F”retagsby AB" 


fran “1 20120101 2012120 ‘(PHO start/end) 
#RAR -1 20120101 20121231 


#UB 0 1210 13360 


#UB 0 


1220 121754.55 


#UB -1 1229 -73815 
#UB -1 1242 -8085 


#RES 
#RES 
#RES 
#RES 
#RES 


In the XBRL file, the concepts of an income statement are linked to a period 
via the contextRef attribute. In the SIE file, a fiscal year date is stated on 
the line beginning with #RAR with the addition of o for the current year and 
-1 for the previous year. The rows that start with #RES links each accounting 
year to account and amounts in the accompanying columns. (#UB stands 


ooo 


3040 -1619620.4 
3500 -576 
3520 -2054 
3610 -487077 
Same metadata 


Different syntax 


for outgoing balance.) 
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This shows that metadata object-wise is structured exactly the same way 
in both document types, but with different syntax (characters between diffe- 
rent data and metadata). 


Summing up, XBRL can be used for statements of balance, assuming a 
given chart of accounts taxonomy in the XBRL standard. Thus, XBRL can 
be used for all documents in the data flow after the coding. Other Nordic 
countries, that do not use the SIE standard in their statements of balance, 
can use XBRL instead. 


Then the document flow (with format in parentheses) looks as follows: 


Transaction Coding => Statement of balanceFinal report 

=> => 

(UBL) (Unknown (SIE or XBRL) (iXBRL) 
format) 


Where is metadata defined? 


However, the correct format does not suffice to unambiguously define the 
data flow. Somewhere in the data flow, metadata/concepts must be defined 
for the entire infrastructure in order to be able to extract meaningful data 
from the flow. (For example, the amount 130,760 must be linked to "Raw 
materials and supplies", as well as to the currency "SEK", as well as to the 
period 2018-01-01--12-31 etc. in order to make the figure meaningful.) 


Metadata from the final reports? 


In Australia, concepts (about 9600) were collected from all government re- 
ports and the taxonomy authors succeeded (through a comprehensive 
harmonization procedure) in reducing the number to 2800 (reducion with 
71 %). In the Netherlands, a similar harmonization work was done, but 
where they could not agree, the concepts were put into different namespa- 
ces. 


A big drawback for metadata defined in the authority reports is that other 
recipients have other concepts/metadata profiles in their databases than 
the public concepts, e.g. banks, insurance companies and credit institutions. 
If the latter organizations want to receive meaningful data, they have to stick 
to authority profiles. Otherwise, the new concepts/profiles of these organi- 
zations must be defined in each software platform. (The software companies 
cannot anticipate what the new concepts will be.) This makes it very hard 
for these organizations to have their own profile. Therefore, there is a lot to 
be said for the fact that metadata should not be defined in the government 
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reports. Futhermore, the software companys will then have to manually 
map all the account codes from each chart of accounts to each report. 


Metadata from the account codes? 


Should metadata (the concepts) be defined on the code level, i.e. a standar- 
dized chart of accounts? 


The companies are obliged to record external and internal transactions 
into their coding. After all, the coding concepts must be defined in their 
accounting. What are the reasons for defining concepts that they will not 
use later? What are the reasons for defining account code concepts that 
are not comparable to the account code concepts defined for other compa- 
nies? There are major advantages for example in mergers and other financial 
co-operation or in comparisons between companies to use common account 
code concepts. 


Since the software companies' platforms must be able to adapt to different 
charts of accounts, especially in countries with a variety of charts of ac- 
counts, they easily should be able to receive a standard chart of accounts 
and also be able to make mappings against it. 


How is metadata passed from a standard XBRL chart of accounts to 
the final reports? 


The summing from the accounts coding in the statements of balance reports 
based on a standard chart of accounts to the concepts of the recipient report 
is generated with calculation linkbases instead of, as today (in Sweden), 
with reference linkbases. Thus, the reports can be generated automatically 
(M2M, machine to machine). Note that the report concepts are precisely 
defined in relation to the chart of accounts. Compromises forming the final 
report concepts, as in Australia, need not be done. If a report recipient wants 
to exclude or add account codes to their concepts relative to the authorities 
in their taxonomy, this is easily made. 


But can summaries be made between different taxonomies? In today's 
taxonomies, Summaries occur only between the concepts within a report. 
The locator element (<loc>) in the calculation linkbase has, according to 
the XBRL standard, a href attribute, pointing to the definition in taxonomy 
schema. The attribute has the data type anyUAI i.e. it can point to any add- 
ress on the internet. This also opens for industry charts of accounts. 


Everything speaks in favor of a standardized chart of accounts, primarily 
adapted so that the regulatory requirements are met, but it should also be 
so diversified that other report recipients can create their own concepts 
based on summations from standard account codes. 
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How do software companies handle a chart of accounts other than the 
standard one? They can make mappings between their own and the stan- 
dard chart of accounts. This mapping needs only to be done once per 
software platform, regardless of how many different reports it will deliver. 


Finally, a standard chart of accounts in XBRL and calculation linkbases that 
link account codes to concepts in the recipient reports will mean that the 
software companies do not have to map account code for account code to 
the right concept in their report generators. The mapping is automized and, 
thus, a source of error disappears. It also means that the report recipients 
define and can take full responsibility for their summations from the standard 
chart of accounts. 


The issue of nodes for receiving reports: Whereto should reports be 
submitted? 


The issue of recipient nodes is solved by having address metadata to which 
the report is to be submitted in the receipient taxonomies (in the common 
data section) by default. Thus, the report is automatically sent to the correct 
address by standard programming (only once) of the software platforms for 
any address. 


Thus, the authorities do not have to build common nodes from which different 
data will later be distributed to each authority. The so-called technique of 
"all in" or "one stop shop" becomes unnecessarily complicated. Using to 
the technique of standard receiving address metadata, every receipient will 
get exactly the desired data in accordance with the receipient's taxonomy 
and calculation linkbases sent directly to the recipient's address. Reporting 
with the iXBRL standard means that the reports are readable and can be 
signed while they also can be stored directly in the recipient's databases. 
With today's technology, the download into the recipient's database will 
then be elementary. 


We still need to link transactions to the coding 


Within the UBL standard it is possible to specify how a transaction can be 
coded. If there are several alternatives to code, the UBL transaction may 
include these. In that case, the user of the software platform may select the 
correct account code from the proposed codes. Otherwise, with one propo- 
sed account code, the coding could be made automatically. 


Summary 


With the proposed infrastructure, the programming time for the software 
companies making final reports will reduce by at least 90 %. APIs can be 
used to generate completed iXBRL code instead of manually making links 
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between account codes and report concepts. Quick reports to new recipients 
are easily created via the APIs from XBRL. An infrastructure with quick and 
accurate reporting based on the account coding is thus made possible. 


In summary, this could be a good start for the development of Nordic Smart 
Business. 

(idl, dg 

Erik Mjöberg l 


1st in the world to be certified by 
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